Illustration by Andrew Krasovitckii
In my first story ‘User Experience is …’ I promised that …
"over the course of a few stories, I’ll try and cover a few of the sciences we draw upon in our art as a creative community to create engaging experiences."
And previously I’ve reflected on how the techniques, methodologies and principles used in both User Experience and Agile are similar in User Experience is ... Agile Coaching. Here I’ll build on that to understand how both principles can work together in a more mature way.
Illustration by Andrew Krasovitckii
Agile and UX are both continuous learning disciplines. We embark at the start of both of these with some knowledge and we learn along the way, increasing certainty and reducing risk. This characteristic should make them obvious partners. Unfortunately though, how Agile and UX are often implemented, they feel very incompatible.
The incompatibility comes from how both have grown organically, without concern for the other. Most teams don’t implement either as effectively as they could, which means they’re already leaving a lot of value on the table. But that lost value is amplified when we try to put these two independent disciplines together. That’s when we most feel the pain.
No small part of this is misinterpretation and blurred lines, meaning no one’s really sure what their role is, what principles they are following, what they are choosing not to, but more importantly why. And sometimes the reason for not following the principles is not because you’ve actively made the decision not to, or you adjust the principal for your team or context, but just because there’s a knowledge gap, blind spot or immaturity.
Much of what holds us back is outdated thinking about what both UX and Agile are. We’re stuck in 2001 when Agile was first conceived, and today’s UX practices were in their infancy. We’ve learned so much in the last two decades. We know how to do better.
Agile and UX can work together. To do that, we need to reframe some misconceptions about how we put them together. We need to replace old, dysfunctional habits with state-of-the-art techniques and processes. We need to ‘be Agile’ and not ‘do Agile’, so we can inspect, learn and adapt. If that sounds familiar it’s because it’s one of the very principles of Agile:
"3 Pillars of Scrum Empirical Process Control (Transparency, inspection and adaption)"
Scrum Alliance
Iceberg of doing and being, Alex Carabi
Sure everyone does scrum ‘by the book’ when they first learn it; they do it parrot-fashion. They need the principles, guide rails, standard and patterns to lean on, in order to know what to do, as they will not yet fully have a grasp on the fundamentals, in order to know the black and white, be able to identify the grey areas and feel comfortable to work in those grey areas. They take the repeatable steps they learn and put them into practise. So they set up up the ceremonies and ‘do agile’ but they aren’t yet being agile
A lot of the principles in Agile follow Japanese believes such as Kaizen (continual improvement) and Kanban (balancing demands with available capacity). Following the same approach scrum can be thought of the same as a martial art.
Shu, ha, ri, is a belief within martial arts use to describe the overall progression of martial arts training. Shu-ha-ri roughly translates to “to keep, to fall, to break away”.
Another analogy which I’ve come across is the learn, do, teach method. Otherwise known as the Feynman Technique. Where you build understanding by maturing through your knowledge. First of all learning the basics, then repeating parrot-fashion, to a degree where you can easily follow a process. Through this experience you’re then able to teach and answer questions from different scenarios and situations to cover more off piste topics and still guide and advise.
This is a way of learning the rules, be able to bend the rules and ultimately break the rules in such a way that it adds value and are able to still be able to guide. So there is a need to relearn what we know, rework how UX and Agile come together and reframe it.
We need to reframe Agile to deliver great UX. For instance we need to look at how we can use UX research to drive the meaning within the “Definition of Done”. We need to explore how to proliferate the definition of “done” with extensive user research, which drives product development to become human centred.
UX metrics for agility need to be defined and established. To complement and support business outcomes, which lead to measures of success for products and services that improve people’s lives. The right UX metrics will show what success and progress look like and how value is realised for the people that use your product or service.
Agile teams need to work autonomously. In any given sprint, the team faces dozens (if not hundreds) of critical decisions affecting the eventual experience users will have. Having reframed Agile and UX will help to keep our design quality high, while each team can work through the decisions themselves. By ensuring that product teams have a shared understanding of user problems, insights and what the user expectations are.
Everyone has the capability to ‘do Agile’, but only more mature teams that have reframed Agile and UX can ‘be Agile’.
So take a thoughtful approach at how both Agile and UX can be improved, with both in mind, to generate dramatically better products and services for people that use your product or service. Build value through the tools and processes the team uses to increase value for users and your organisation.
Next up I’ll share What we learned from using a North Star, when we experimented with moving away from feature roadmaps and focussed on outcomes and value. Both within the overarching strategy but also how this filters down into the products that we were designing and building to overcome the problems we’d identified.
Originally written as part of the ‘User Experience is …’ series for UX Collective.